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ABSTRACT 



A system including any number workstations, file servers, 
printers and other fixed devices coupled in a network, and a 
number of portable devices carried by users and coupled to 
the network by infrared (IR) link. Each portable device 
emulates its user's personal satchel for documents: the 
device is programmed to receive transmit and store docu- 
ment or service tokens (tokens). Preferably, the token com- 
prises a plurality of components defining a document related 
entity and a property of the entity, the token components 
including an operation component designating a document 
related operation, an address component designating the 
electronic address of a document or system providing a 
document related service, one or more parameter 
components, each parameter component defining a property 
of a document or a property of a service to be applied to a 
document, and a security parameter dependent upon the 
identity of a user associated with a document or with a 
document related service. The tokens are distributed from 
one person to another by transmission of IR data packets, 
and once a network-connected computer, printer or multi- 
function device has received a token via IR transceiver 
associated with it, a search request can be derived from the 
token and document references (e.g. WWW URLs) satisfy- 
ing the token can be obtained via a search engine. For each 
URL obtained, the corresponding electronic document can 
be retrieved from a repository and displayed or printed. The 
portable device is preferably a handheld or wristwatch 
computer with a graphical display for enabling the user to 
transfer tokens, and the fixed devices preferably include a 
scanner/copier/printer having its own IR transceiver. 

21 Claims, 8 Drawing Sheets 
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TOKEN-BASED DOCUMENT 
TRANSACTIONS 

FIELD OF THE INVENTION 

The present invention relates to data processing, and more 
particularly relates to the transfer between computing 
devices, and the retrieval by such devices, of document 
related information. Even more particularly, the invention 
concerns such information retrieval, transfer and processing 
using tokens. 

BACKGROUND AND SUMMARY OF THE 
INVENTION 

While the use of portable computing devices is becoming 
more widespread, transfer of information between such 
devices is often limited due to inadequate storage capacity or 
communication channel bandwidth. One possible system for 
overcoming as these limitations is disclosed in European 
patent application EP-A-691,619, published Jan. 10, 1996 
(hereafter "EP*619"), which discloses a system for transfer- 
ring document identifiers representing a particular document 
between computers, rather than the document itself. This 
system can include any number workstations, file servers, 
printers and other fixed devices (including multifunction 
devices) coupled in a network, and a number of portable 
devices (e.g. handheld or wristwatch computer) carried by 
users and coupled to the network by infrared (IR) link. Each 
portable device is in effect a user's personal satchel for 
documents, with the devices being programmed to receive, 
transmit, and store document identifiers (e.g. World Wide 
Web URLs), each of which is associated with an electronic 
document stored in an electronic repository at a site on the 
web. Documents are effectively distributed between devices 
by transmission of document URLs, rather than the lengthy 
document itself. For example, a document can be sent to an 
IR transceiver equipped network printer by "beaming" that 
document's URL from a handheld portable computer to the 
network printer The network printer retrieves the complete 
document referenced by the URL, and immediately prints a 
copy. 

While useful, the foregoing system may not always sup- 
port operations, security measures, or parameters required 
by mobile workers interacting with various computational 
devices in the workplace. For example, a network printer 
beamed a document identifier might print the document as 
single sided using its default settings, even though the 
mobile worker may actually desire double sided printing. 
Accordingly, the present invention provides a method for 
supporting a wide range of digital applications that can be 
carried out in a data processing device that includes a 
processor, memory, and a user interface. In response to user 
input, the data processing device can generate a token 
comprising an operation component designating a document 
related operation (e.g. single sided or double sided print 
command), an address component designating the electronic 
address of a document or system providing a document 
related service, one or more parameter components, each 
parameter component defining a property of a document or 
a property of a service to be applied to a document, and a 
security parameter dependent upon the identity of a user 
associated with a document or with a document related 
service. This token is transmitted to another device (e.g. the 
network printer), which can check security, parameters, and 
modify its default operations in response to user input to the 
data processing device. 
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The invention employs "Satchel Document Tokens" — a 
special form of reference to a document or to a document 
service in portable devices, systems and methods for sup- 
porting mobile worker's document activities. These Satchel 

5 Document Tokens are henceforth simply referred to as 
"tokens". In accordance with the invention, tokens can be 
stored in small personal portable electronic devices and can 
be transmitted between holders of such devices. They can 
also be transmitted to appropriately equipped document 

10 devices (printers, scanners, copiers, faxes). Tokens contain 
the information necessary to access documents, to invoke a 
document services with appropriate parameter settings, or to 
initiate the actions of a document device with appropriate 
parameter settings. In addition, the token contains the secu- 

15 rity information which provides safeguards to ensure that 
unauthorized use of the documents or document services 
that are referenced in the token is precluded. 

In preferred embodiments, a token contains at least the 
following components. 

20 Basic Operation. The token specifies the particular opera- 
tion that is to be performed, e.g. getting the document or 
performing a service (printing, scanning, faxing, 
converting). The action may be identified very genetically 
here, with parameter settings used to identify the exact 

25 operation more specifically. 

Address of document or document service. The token 
contains the information necessary to find the document or 
service. The address could consist of the network address of 
a server and the file path name of a document. A WWW 

30 Uniform Resource Locator (URL) is an example of a 
document address, and is used in the current Satchel proto- 
type. 

Parameters. The token contains a set of parameter settings 

35 that may be needed by subsequent services that are triggered 
by transmitting the token to a device. Parameters are used to 
further specify the document or document service (e.g. 
Number of copies to print). Some parameters may them- 
selves be tokens. The specific types parameters required 

4Q depends on the particular service. 

Visible Name. The token contains a string or icon which 
can be displayed to identify the document or service to 
which the token refers for the benefit of the user. 

Security Information. The security component of a token 

45 contains information to support ensuring that only the 
intended use of the token is possible. 

The security information includes a digital signature of 
the information in the token. The digital signature is a digest 
of information in the token and its encryption with the 

50 document owner's private key. This follows well known 
prior cryptographic art relating to public/private key cryp- 
tography (see U.S. Pat. No. 4,405,829). These signatures can 
only be generated by the personal portable device since only 
it has the private key. The signature ensures the integrity of 

55 the token and attests that the token did originate from a 
known portable device. 

The security information can also include specified con- 
ditions that will restrict access to a document. For example, 
it may include (1) an expiry date beyond which access to the 

60 document is no longer granted, (2) the condition that a 
payment or certificate for release must be associated with the 
token, and/or (3) a requirement that only a given device be 
used to print the document. 

The security information can include a recipient's public 

65 key or name to indicate that the returned document be 
encrypted with the given public key or the known public key 
associated with the recipient's name. This ensures that only 
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the intended recipient of the document can make use of the 
returned document and that an intercepted copy of either the 
encrypted document or the token is of no use to anyone other 
than the intended recipient. More generally, information for 
supporting fees and usage rights such as can be expressed in 5 
more complex fees and usage rights languages (such as 
described in Stefik, M., "Letting Loose the Light: Igniting 
Commerce in Electronic Publication. In Internet Dreams: 
Archetypes, Myths, and Metaphors. Edited by Mark Stefik. 
MIT Press, 1996), may be associated with the token. ao 

Tokens which include security information are presented 
to "secure documents servers". A secure server contains a 
"gatekeeper" which verifies signatures on tokens and exam- 
ines the specified conditions associated with the token and 
then acts accordingly (e.g. encrypting the document with the 15 
appropriate key). The public key for verifying the signature 
is obtained through a parameter in the security information 
which identifies the owner of the document or from a server 
which stores users' public keys. 

As compared to conventional technology for document 20 
transfer and processing, token-based techniques in accor- 
dance with the present invention have various advantages, 
including: 

(i) Portability — A laptop is generally too heavy to carry 
everywhere all the time. Tokens can fit into smaller 25 
amount of memory which will require less power, 
allowing the device to be even smaller. The smaller a 
device, the more easily it can be carried everywhere. 

(ii) Serving unanticipated needs — If the user has forgotten 3Q 
to take the paper document or electronic document, he 

or she cannot give the document. A Satchel user can 
always provide a token for a document. There is no 
longer the burden of having to remember which docu- 
ments to take. 35 

(iii) Speed — A wireless transfer of a token between 
devices will always require less communication time 
than a wireless transfer of the actual document. This 
streamlines and speeds up the transfer transaction and 
improves its reliability. The lower transmission power 4Q 
requirements contribute to keeping the device small. 

(iv) Ease of remote login — When using a laptop, the user 
attempts to find a means to login remotely to his/her 
home office machine or server to access documents. 
This is awkward and complicated, the physical con- 45 
nection devices may be wrong, access to the local 
network may be barred (no local login), or dial-up to 
home office may be expensive and slow. This is alle- 
viated by providing the security information compo- 
nent in the token. 50 

(v) Document transfer — Transferring an electronic docu- 
ment from one user to another is awkward, since the 
users must have a medium (floppy disks, which may be 
too small) or laptop-laptop network which will be 
clumsy to set up. Also, with tokens, any associated 55 
processing (e.g. format conversion) of a document can 

be performed when the token is submitted ("cashed - 
in") and anywhere where applications for processing 
are available. 

(vi) Support for dynamic documents — A token can con- 60 
tain a reference to a document whose contents change 
(e.g. a weather forecast). The user can thus give a token 
for "he latest version" of a document. This is not 
possible with a static copy of the document from paper, 
laptop or floppy. 65 

(vii) Security improvement — The loss or theft of the 
device doesn't mean documents are immediately 



accessible, only tokens. The secure server can be 
instructed to no longer honor tokens from the device 
(analogous to revoking a credit card). In the case of 
using a laptop or floppy, either the data is stolen, or the 
user must ensure all data on the laptop is encrypted. 
A further benefit is in the enablement of diverse 

document-related activities, examples of which are given 

below. 

(i) Tradable services. By encapsulating services in tokens, 
they can be passed on and distributed just like docu- 
ment tokens. 

(ii) Partially Specified Services: The service may only be 
partially specified in the token. A simple example of a 
partially specified document service is one which prints 
a given document in a particular way on a printer (e.g. 
duplex two-up). The remaining specification of the 
service (e.g. the actual printer, the number of copies) 
may not yet be specified, but the token can nonetheless 
be passed from one user to another. The recipient can 
then use it as a known, reliable, and easy way of having 
a specific service performed, with their choice of fur- 
ther options. 

(iii) Network supplied processing: The burden is on the 
token-enabled servers on the network to get the desired 
action performed, not on the limited personal device. 
By using tokens, neither the data nor the application of 
the document need be locally present, either on the 
portable device itself or at any local server. Service 
execution and invoking applications for particular data 
formats can be performed where the appropriate soft- 
ware is available. 

Additional functions, objects, advantages, and features of 
the present invention will become apparent from consider- 
ation of the following description and drawings of preferred 
embodiments. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates schematically a portion of the network 
infrastructure which may be used to implement embodi- 
ments of the invention; 

FIG. 2 shows a portable computing device used in accor- 
dance with an embodiment of the invention; 

FIG. 3 illustrates schematically the components of a token 
used in accordance with an embodiment of the invention, (a) 
in general form, and (b) the document form; 

FIG. 4 is a schematic flow chart of the steps in exchanging 
tokens in accordance with an embodiment of the invention; 

FIG. 5 is a schematic diagram of the steps involved in the 
transfer, in accordance with an embodiment of the invention, 
of a token between a portable computing device and one or 
more fixed devices; 

FIG. 6 is an illustration of the steps involved, in accor- 
dance with an embodiment of the invention, in decoding the 
token of FIG. 3, once received; and 

FIG. 7 is a schematic flow chart of the steps involved in 
carrying out the appropriate action as specified in the token 
as received as in FIG. 6. 

DETAILED DESCRIPTION OF THE DRAWINGS 
1. System Hardware 

As will be appreciated, the present invention may be 
implemented using conventional computer network 
technology, either using a local area network (LAN) or, 
more suitably, a wide area network (WAN). The invention 
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has been implemented using conventional web browser actions which produce the desired result. For example, 

software (e.g. Netscape) providing cross-platform commu- printing out a document only needs a simple interaction: The 

nication and document transfer over the internet. However, document's token is selected on the user interface of the 

it will be appreciated that the invention may be implemented small device. This token is incorporated as a parameter of a 

using different system configurations: see EP'619. It will be 5 token identifying the print service. When the latter token is 

appreciated that each fixed machine forming part of the received by the server software via a wireless and then a 

network may be a PC running Windows™, a Mac running wired connection (e g. an infrared receiver which is tethered 

MacOS, or a minicomputer running UNIX, which are well * 1 [oc f netwo *)' < he a f °° the r f ei P l of th f 

known in the art, or any suitable processor-controlled net- lol f ™*°™% s ^ do ™' 

1 il t"*/^> l j c *• „ and printed. In this way it is only the token that is transmitted 

work computer. For example, the PC hardware configuration to ^ ^ ^ yia means an(J 

is discussed in detail in The An of Electronics, 2nd Ed Ch. then jt fe fij[ed) wiredj communications that is then used to 

10, P. Horowitz and W. Hill, Cambridge University Press, move the actua] docuraent data> appropriately processed, to 

1989. tne end device ( a printer in this example). The net effect is 

Upon request of a user at a first machine, a document that a user can produce a desired action in a quick and simple 

stored on a second machine may be retrieved and sent from 1S W ay. 

the second machine over the internet, via any number of 2 . Satchel Token— Components ("Packet Encoding") 

intermediate machines to the first machine. Also, the docu- nGS 3((j) ^ v ft) are xhlimSltic diagrarns of the eon- 

ment may be retrieved using as a unique identifier its World , ents of a Satchel Token ^ show> abstracU y, the main 

Wide Web URL, as discussed in EP 619. Preferably also components of a Satchel Token . FIG . 3(fl) ^ me more 

connected to the network are any number of processor- 2" ^ ^ specifies tfae struct ure of any token, 

controlled printers, scanners, fax machines or multifunction whether it ^ for a service or for a document. FIG. 3(b) is a 

devices (capable of scanning, printing, copying and/or simpler version of the same token^Dne which specifies the 

faxing, etc.), as discussed in EP'619. Each machine coupled form of a Satchd Token when the , oken onl embodies a 

to the network is also equipped with appropriate hardware st . ht documeal request . 

and software, which is known in the arU for communication 25 ^ ^ ^ ^ ^ fou descr i ption( text 

with portable computing devices, such as personal digital & ^ t which & have 

assistants (PDAs), handheld PCs, or pocket or wristwatch components (e g Se(vice F p arame , ers) . Boxes and lines 

computers. which are dashed indicate components which may be 

As shown in FIG. 1, a pervasive computer network 21 has present in some tokens, but need not be present in all tokens, 

an infrared transceiver 22 for each room, desk, workstation, i ^ lhey are not required i n order to make a valid Satchel 

copier, printer etc., coupled thereto. (For the sake of clarity, Token 

only one transceiver 22 is illustrated). In addition, however, Referring to FIG. 3(a), the components (32, 34, 342, 344, 

the network 21 is coupled to the conventional telephone ^ 38> 382 . 389) of the al form of the satchel token 30 

network 24 by means of gateway 26, which is known in the afe schematically mustr ated. All the components (32, 34, 

art. In this way, the portable computing device 2 is able to ^ ^ ^ ^ 382 _ 389) taken together form a Satchel 

communicate with devices on the network 21 not only by IR Jokcn al 3Q n are st0fed inside a user > s pDA2 (but 

signals to/from transceivers 22 but also (when additionaUy tfa caQ ^ be stored ifl usef , s flal computers/ 

or alternatively provided with distal radio frequency com- workstations) ^ smaU packets having the structure indicated 

munications hardware (not shown)) by RF signals to/from a {q rg 3 ^ are taken out of tWs form and ]inearised 

digital cellular base station 28 of the telephone network 24 (made imo a strai ht Hnear nce of ASCII characters) 

Suitably, the RF communications hardware (not shown) when needed ^ cfln fee done fof ^ & sQ ^ 

complies with the GSM digital standard, thereby permitting a ^ C&Q be tra ted throu ^ ^ communications 

transmission of digital data between the portable device 2 medium (wifed Qr and ^ that the token as a 

and the base station 28, which suitably comprises a GSM ^ who]e can be taken ^ a lkear o[ASCU characters 

receiver/transmitter. for secure hashing and then digital signing operations to 

While a preferred form of portable computing device is form the token's digital signature component, 
shown in FIG. 2, it will be appreciated that the computing -j^ general token 30 includes a Service Host Identifier 32 
device may be fabricated in a multitude of forms: for wnicn identifies a host machine on a network. This compo- 
example, the device 2 may be of any of the forms disclosed 5Q nent indicat es to the system where the document or service 
in U.S. Pat. No. 5,982,520 ("Personal storage device for ^ ava ilable from a host machine on the network. Typically 
application and data transfer", filed Mar. 28, 1996). In its this ^ in the form of a standard Internet Fully Qualified 
preferred form, each portable computing device 2, and each Domain Name. The Service Host Identifier 32 need not be 
of the fixed machines on the network, is equipped for filled into the token 30 by the user's PDA 2. This flexibility 
infrared communication. Data packets transmitted between 55 k esS ential in order to implement the context sensitive 
the computing device 2 and the fixed machines enable the capabilities feature of the Satchel System. This component 
documents) to be retrieved, and conform to the physical and 32 of a token 30 may be fiUed m at a later stage irj the 
link layer formats (IrLAP) described in the industry standard processing of a token 30. For example, the infra-red trans- 
Infrared Data Association (IrDA) specification, version 1.0, ceiver device whicD acC ept s and conveys tokens can fill in 
which is well known in the art. 6Q the Service Host Identifier 32— in order to specify a Service 

The tokens concept described here provides an essential Host Identifier 32 that is appropriate for that transceiver 

component of a system solution that addresses these needs device's location. 

of the mobile worker (e.g. Satchel; EP '619), within the Authorization— The general token 30 includes a compo- 

technological constraints described above. nen t 34 which in turn contains the two main security 

A token contains the small amount of essential informa- 65 components. It provides the means by which the system can 

tion which allows the system (token-capable server software verify that the token is genuine and has not been tampered 

resident on public networks and private networks) to initiate with. 
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The first security component is an Authorizer Identifier it, an expiry date for the validity of the token, a restriction 

342 — This component indicates the person that created the on the type or identity of the device that the document can 

token 30. The Authorization identifier 342 may be as simple be printed on. Additionally, a full specification of the digital 

as an ASCII string of the user's name, or be as complex as property rights of the document can be added using a 

a full X.509 identity certificate (see ITU-T Recommendation 5 statement in a digital property rights language (DPRL) (see 

X.509— CCITT document "The Directory-Authentication the abovementioned M. Stefik reference). Since tokens 30 

Framework"). The second security component is an Autho- can tokenS) security restrictions that must be salis- 

rizer Digital Signature 344, which is a string created by the fied can be with tokens at each level> 

following method: (a) linearise all other components in the „ _ . ^„ „ . 

token to produce an ASCII string, (b) produce a hash of the 1ft ,, **&mag now to FIG. 3(6), tins is a simplification of FIG 

string using any suitable well-known secure hash function 10 !>(«). a ° d shows ' he .f^P 1 " fo ™ , of £bo-* Satchel 

(e.g. MD5, SHA; see Applied Cryptography by Bruce Token/Document (or "Document Token ) 40-when the 

Schneier, 1996, John Wiley and Sons), and (c) encrypt the 1S , ™?£ a re ? uest t0 access , a document. In FIGS, 

hash with the user's private key, which is only kept in the ?(a) and 3(b) like reference numerals denote like elements. 

PDA. Note that the Authorizer Digital Signature 344 itself is „ ,n ° f * e 40 °J "G. 3(b), the component 

not part of the hash, but the Authorizer Identifier 342 is. 15 ^^.^ ' he Semce "enufier 36 is Document Identifier 

Another component of the general token 30 is the Service ? 6 ' J^^T t0 ** V*™**™ d °~ » 

tj ic t-u p u i C «• 4 . located. Also, the component embodying the Service Host 

Identifier 36. The Service Identifier 36 is a component which M . ^ r . IT , TJ .Jf A * A , c . L 

. , ,. r ... /j .v.i. . ■ . i Identifier 32 is the Document Host Identifier 42. Also, for the 

identities the particular service (or document) that is to be , iAl 4n , j ■ * j 

, t/ r , n , . 1C v r 4l _ a c * r,L document token 40, a component designated Document 

invoked (or requested) on behalf of the user. A feature of the ™ r» . Aa . . . , , ™ . ~ . ... 

system according to the invention is that this Service Iden- 2 ° Parameter * 48 £ included. This component itself has several 

tifier 36 may only identify a general class of service, with the c °*P° ne Jf *™ <° further specify the document 

# ! • u * i ju ■ j j j * *l * request. The Document Parameters 48 includes a Document 

actual service being invoked being deduced by the system VT ^ 4 . ,. . , „ 

from this Service Identifier 36 and the additional Service Namc . f ap0D ™ l A 48 ?' ^dicating how the document is 

Parameters (discussed below) provided. „ ( named for v ,f ble , m , lbe ™ A user interface-..e. a 

z * title, as well as satchel token 389 and Further Security 

I Tie general token 30 includes a further component des- Parameters as in FIG 3(a) 

ignated Service Parameters 38. This component itself has . ' J, ' 

several components 382-389 which serve to further specify 3 * Transacll0ns Wltn Tokens 

the service request. The Service Parameters 38 includes FIG. 4 is a schematic flow chart of the steps in exchanging 

Service Name 382, which identifies how a service is iden- 30 a token (between the PDAs of users A and B), in accordance 

titled to the user as a visible name in the user interface of the with an embodiment of the invention. Initially (step si) an 

PDA 2. This may be simply a familiar name, e.g. "Print" or is received from user A, requesting the transmission of 

"Scan" or "Fax", a graphic icon, or can be more complex, a token * T^s request may be input by user A via the user 

e.g. a type-in form to be filled in by the user. Also included interface of the PDA by means of button presses, selection 

in Services Parameters 38 is Satchel Token 384. A Satchel 35 from P ul1 dowc menus, and/or dragging and dropping of 

Token 30 can itself contain zero or more further Satchel icons > as is wcl1 knovrn m the art (see, e -g- EP'619). 

Tokens 384,389. This is a key aspect of the design of this In response to the user request, the PDA of user A 

invention in that it allows more complex user requests to be (hereafter PDA A) transmits (step s2) a query (by wireless, 

created in the form of Satchel Tokens 30 which are com- and preferably IR, signals) for the context of user A, i.e. for 

posed of other Satchel Tokens 384,389. This is indicated in 40 the identification of the users (here: B) of those PDAs which 

FIG. 3 by the Satchel Token boxes 384,389. They can are in range of communication. Next, the PDA of user B 

contain another full token, be it a General Satchel Token 30 (hereafter PDA B) receives the context request query and 

or simple Document Satchel Token 40. prepares a response (step s3). Once compiled in suitable 

The Service Parameters 38 further includes Context/ form, the "Service available" reply is sent (step s4) by PDA 

Location Parameters 386. This component contains param- 45 B - This amounts to saying that it is OK to send the token 

eters which identify the context in which the request is from user A's PDA to that of user B. When sending this 

made. The parameters may be filled into the token 30 either reply* PDA B can provide a user identity or cryptographic 

by the PDA device 2 itself or the wireless transceiver devices ke Y (public) associated with the "Service Available" infor- 

(infra-red) 22. The location parameters 386 can include, for mation. 

example: the type of document device (printer, scanner, fax) 50 Once the "Service Available" indication is received by 

that the transceiver is attached to, the local name of the PDA A, user A is prompted to make a further selection (step 

document device, the room in which the request was made, s5) via the user interface of PDA A, corresponding to the 

the time when the request was made, the country in which action "Beam Token to User B" — see EP'619). Then, at step 

the request was made. s6, the necessary components (see FIG. 3) are assembled 

As shown, as part of the Service Parameters 38, Further 55 and the token (30, 40) constructed. This is followed by the 

Service Parameters 387 may be included. This component wireless transmission of the token (i.e. as an IR data packet) 

contains parameters which can specify the particulars of a (step s7) from PDA A to PDAB. Once received (step s8) at 

request even further. Examples of Further Service Param- PDAB, the newly-arrived token is stored in PDAB (step s9) 

eters 387 include: the number of copies to be printed, the in the conventional manner, and this may be with or without 

phone number of a fax machine that a document is to be 60 further intervention by user B to place (an icon for) the 

faxed to, the name of a scanned document. In addition, newly- received token in an appropriate directory, 

another component of the Service Parameters 38 may be FIG. 5 is a schematic diagram of the steps involved in the 

Further Security Parameters 388. The use of the token 30 can transfer, in accordance with an embodiment of the invention 

be restricted, and these restrictions supported, by indications of a (print service) token between a portable computing 

in the Further Security Parameters component 388. Such 65 device (PDA) and a fixed device (printer) in order to 

additional information can include: a cryptographic key to accomplish the printing of a document. The top part of FIG. 

use to encrypt a document when the token is used to request 5 is the same as FIG. 4, except that PDA B is replaced by an 
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IR transceiver 22 on the network 21 of FIG. 1: the trans- 
ceiver 22 may by physically attached to (and electronically j 
coupled to) or embedded in, the printer on which it intended 
to print the document. Also, steps si' to s8' in FIG. 5 
correspond to the steps si to s8 of FIG. 4, except that the 5 
service is a "Print Document" service, and the token trans- 
mitted is a Satchel Print Service token. Parameters (see FIG. 
3) corresponding to the specific action to perform, in this 
case printing, may be incorporated into the token either by 
the PDA 2 when assembling the token (s6, s6') or by the 30 
transceiver 22 upon receipt, depending on the circum- 
stances. 

In FIG. 5, step s8' is followed by the step (slO) of adding 
parameters to the received satchel (print service) token: 
these may include any of the (components of the) parameters 15 
38, 48 of FIG. 3. Once the parameters have been appended 
to the token, the token is sent over the network to worksta- 
tion 50. At workstation 50, upon receiving the token, the first 
step (sll) is to decode the token: this involves checking the 
Authorization (see FIG. 3), and is described in more detail 2 o 
below in connection with FIG. 6. Then, the token is analyzed 
at step sl3: the substeps constituting the procedure of step 
sl3 are described in more detail below with reference to 
FIG. 7. An element of this routine is the request for a 
document held in an electronic repository — here it is illus- 2 $ 
trated as being stored on a remote file server 52 (which may 
be in a different building or in a different country), although 
it will be appreciated that the document could be stored 
locally on the workstation 50. Thus, in order to request the 
document the document token is sent (step sl4) to file server 30 
52 where it is decoded (step sl5) upon receipt, so as to 
extract the Document Identifier 46 (see FIG. 3(b)), e.g. a 
WWW URL. Using the Document Identifier 46, the docu- 
ment data (electronic file) are retrieved by the file server 52. 
The document data are then sent over the network at step 35 
sl7, in the conventional manner, to the workstation 50 which 
originally received the Print Service token. Once the docu- 
ment data are received at the workstation 50, a check is made 
to see whether the data must be converted (to a different 
format), and if so, the conversion is carried out at step sl8. 40 
For example, printer 54 associated with transceiver 22 may 
be capable of printing only in PostScript® format; and step 
slO therefore included adding parameters to the token des- 
ignating that the data file sent ultimately to the printer must 
be converted to PostScript® format. Following conversion 45 
(if necessary), the (converted) document data are sent (step 
sl9) to the printer 54. Upon receiving the document data, the 
document is printed (s20) by the printer in the conventional 
manner. 

FIG. 6 shows in detail the substeps of the decode Satchel 50 
token step of FIG. 5. First the linear ASCII string form of the 
token as received at workstation 50 is recreated in its 
structured form, as shown in FIG. 3. Then, a test is made at 
step sl24 to see if the X Authorization Digital Signature 
(344; FIG. 3) verifies. If the test is failed, an "Authorization 55 
verification failure" message is returned (step sl26), i.e. 
output to the user in a conventional manner. If success is 
obtained in the test of step sl24, the action (service) — here 
printing a document — is invoked by workstation 50, as 
described elsewhere. 60 

FIG. 7 shows in detail the substeps involved in the 
Analyze Token step in FIG. 5. Initially, the print service is 
invoked (step sl31), by virtue of the Service Identifier 
parameter 36 (FIG. 3) designating a print request. Then, the 
Service Parameters 38 (FIG. 3) are examined (step sl32); for 65 
example, the printing device which is to perform the print 
(service) may have been specified by user (and included as 



a parameter) prior to transmitting the token, or may have 
been added (step SlO; FIG. 5) based on context/location 
parameters 386 (FIG. 3(a)). The token may include further 
service parameters, as discussed in Section 2 above. This 
enables the exact print service required (e.g. printer id, 
number of copies, 2-sided, etc.) to be deduced (step sl33). 

Once this has been done, the document to be printed is 
requested (step sl34), and the document token sent to the file 
server (see FIG. 5). Then, the capabilities of the chosen 
printer are examined (step sl35): this may show that the 
printer can only print with a certain paper size, with only 
certain fonts, or only documents in PostScript® format, for 
example. In this way, the conversion techniques which need 
to be performed on the document data received from the file 
server (52; FIG. 5) can be determined (step sl36). Then, 
once the document data are sent (sl7) to the workstation 50 
(FIG. 5), the necessary conversion can be carried out (step 
sl8) prior to dispatch of the document to the chosen printer. 

As those skilled in the art will appreciate, other various 
modifications, extensions, and changes to the foregoing 
disclosed embodiments of the present invention are contem- 
plated to be within the scope and spirit of the invention as 
defined in the following claims. 

What is claimed is: 

1. A system for accessing electronic documents in a 
repository of electronic documents coupled to a wire based 
network, the system comprising: 

(A) a mobile data processing device, comprising: 

(a) a processor with coupled memory, 

(b) a user input module coupled to the processor to 
generate a document related user input that specifies 
a document related service to be performed on a 
document stored in the repository of electronic 
documents, 

(c) a token building module coupled to the user input 
module for receiving the document related user input 
and constructing a general token including: (i) a first 
service parameter defining a first property of the 
document related service and (ii) an address compo- 
nent designating an electronic address of the docu- 
ment in the repository of electronic documents to 
which the document related service is to be 
performed, and 

(d) a wireless transceiver for transmitting the con- 
structed general token; 

(B) a wired transceiver coupled to the wired based net- 
work for communicating with the mobile data process- 
ing device to receive the general token; the wired 
transceiver specifying a second service parameter 
defining a second property of the document related 
service in the general token; and 

(C) a workstation coupled to the wired based network for 
communicating with the wired transceiver to receive 
the general token; the workstation analyzing the service 
parameters in the general token to deduce a document 
service system for performing the document related 
service specified in the general token on the document. 

2. The system according to claim 1, wherein the work- 
station examines capabilities of the document service system 
for determining and carrying out conversions to the docu- 
ment prior to transmitting the document to the document 
service system for performing the document related service 
specified in the general token on the document; wherein the 
conversions carried out on the document put it in a format 
suitable for processing at the document service system. 

3. The system according to claim 1, wherein the reposi- 
tory of electronic documents forms part of the workstation. 
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4. The system according to claim 1, wherein the work- 
station analyzes at least one of a single or double sided 
copying parameter and a number of copies parameter in the 
service parameters to deduce the document service system 
for providing the document related service. 

5. The system according to claim 1, wherein the wired 
transceiver specifies the second service parameter in the 
general token using a context/location parameter. 

6. The system according to claim 5, wherein the service 
parameters of the general token further includes an elec- 
tronic address of the document service system for providing 
the document related service. 

7. The system according to claim 5, wherein the general 
token further includes a security parameter that is verified by 
the workstation. 

8. The system according to claim 7, wherein the security 
parameter specifies a digital property right in a digital 
property rights language. 

9. The system according to claim 7, wherein the security 
parameter specifies one of a digital signature, a digital 
property right, a cryptographic key to encrypt the document, 
an expiry date for the validity of the first token, and an 
authorizer identifier. 

10. The system according to claim 1, wherein the param- 
eter component is one of a single sided print command, a 
double sided print command, number of copies to be printed, 
a phone number of a fax machine that the document is to be 
faxed to, and the name of a scanned document. 

11. The system according to claim 1, wherein the docu- 
ment related service includes one of a print service, a fax 
service, and a scan service. 

12. A wireless data transfer procedure carried out in a 
system for accessing electronic documents in a repository of 
electronic documents coupled to a wire based network, the 
system including: a mobile data processing device, com- 
prising: a processor with coupled memory, a user input 
module coupled to the processor to generate a document 
related user input, a token building module coupled to the 
user input module, and a wireless transceiver; a wired 
transceiver coupled to the wired based network for commu- 
nicating with the mobile data processing device; and a 
workstation coupled to the wired based network for com- 
municating with the wired transceiver; the wireless data 
transfer procedure comprising: 

(a) receiving at the token building module the document 
related user input that specifies a document related 
service to be performed on a document stored in the 
repository of electronic documents; 

(b) responsive to (a) constructing at the token building 
module a general token including: (i) a first service 
parameter defining a first property of the document 
related service and (ii) an address component designat- 
ing an electronic address of the document in the reposi- 
tory of electronic documents to which the document 
related service is to be performed; 

(c) transmitting using the wireless transceiver the con- 
structed token to the wired transceiver; 

(d) responsive to (c) specifying at the wired transceiver a 
second service parameter defining a second property of 
the document related service in the general token; 

(e) responsive to completing (d) transmitting the general 
token from the wired transceiver to the workstation 
over the wire based network; and 

(f) analyzing at the workstation the service parameters in 
the general token to deduce a document service system 
for performing the document related service specified 
in the general token on the document. 
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13. The wireless data transfer procedure according to 
claim 12, wherein the wired transceiver specifies the second 
service parameter in the general token using a context/ 
location parameter. 

14. The wireless data transfer procedure according to 
claim 12, further comprising examining at the workstation 
capabilities of the document service system to determine and 
carry out conversioas to the document prior to transmitting 
the document to the document service system for performing 
the document related service specified in the general token 
on the document; wherein the conversions carried out on the 
document put it in a format suitable for processing at the 
document service system. 

15. The wireless data transfer procedure according to 
claim 14, wherein the general token is constructed with 
service parameters that include an electronic address of the 
document service system for providing the document related 
service. 

16. The wireless data transfer procedure according to 
claim 15, wherein the general token is constructed with a 
security parameter that is verified by the workstation. 

17. The wireless data transfer procedure according to 
claim 16, wherein the security parameter specifies a digital 
property right in a digital property rights language. 

18. The wireless data transfer procedure according to 
claim 16, wherein the security parameter specifies one of a 
digital signature, a digital property right, a cryptographic 
key to encrypt the document, an expiry date for the validity 
of the first token, and an authorizer identifier. 

19. The wireless data transfer procedure according to 
claim 12, wherein the parameter component is one of a 
single sided print command, a double sided print command, 
number of copies to be printed, a phone number of a fax 
machine that the document is to be faxed to, and the name 
of a scanned document. 

20. The wireless data transfer procedure according to 
claim 12, wherein the document related service includes one 
of a print service, a fax service, and a scan service. 

21. A system for accessing electronic documents in a 
repository of electronic documents coupled to a wire based 
network, the system comprising: 

(A) a mobile data processing device, comprising: 

(a) a processor with coupled memory, 

(b) a user input module coupled to the processor to 
generate a document related user input that specifies 
a document related service to be performed on a 
document stored in the repository of electronic 
documents, 

(c) a token building module coupled to the user input 
module for receiving the document related user input 
and constructing a general token including: (i) a first 
service parameter defining a first property of the 
document related service and (ii) an address compo- 
nent designating an electronic address of the docu- 
ment in the repository of electronic documents to 
which the document related service is to be 
performed, and 

(d) a wireless transceiver for transmitting the con- 
structed general token; 

(B) a wired transceiver coupled to the wired based net- 
work for communicating with the mobile data process- 
ing device to receive the general token; the wired 
transceiver specifying a second service parameter 
defining a second property of the document related 
service in the general token; and 

(C) a workstation coupled to the wired based network for 
communicating with the wired transceiver to receive 
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the general token; the workstation analyzing the service 
parameters in the general token to deduce a document 
service system for performing the document related 
service specified in the general token on the document; 
wherein the workstation examines capabilities of the 5 
document service system for determining and carrying 
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out conversions to the document prior to transmitting 
the document to the document service system for 
performing the document related service specified in 
the general token on the document. 

* * * * * 
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